InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / noop / plans / barns next >

Wrap

Internet Message Format | 1991-07-30 | 26.0 KB

From noop-owner@merit.edu Mon Jul 29 19:10:44 1991 Received: Mon, 29 Jul 91 19:10:40 EDT by rivendell.merit.edu (5.51/1.6) Received: by merit.edu (5.65/1123-1.0) id AA02484; Mon, 29 Jul 91 19:08:07 -0400 Received: from gateway.mitre.org by merit.edu (5.65/1123-1.0) id AA02480; Mon, 29 Jul 91 19:08:00 -0400 Return-Path: <barns@gateway.mitre.org> Received: by gateway.mitre.org (5.61/SMI-2.2) id AA12816; Mon, 29 Jul 91 19:07:26 -0400 Message-Id: <9107292307.AA12816@gateway.mitre.org> To: noop@merit.edu Cc: barns@gateway.mitre.org Subject: Document by Barns, "OSI Network Addresses for the DOD Internet" Date: Mon, 29 Jul 91 19:07:21 -0400 From: barns@gateway.mitre.org Status: RO OSI Network Addresses for the DoD Internet Draft Version 4 - 23 January 1991 SECTION 1 BACKGROUND AND ASSUMPTIONS The U.S. Government has made a policy decision that the Open Systems Interconnection (OSI) communication protocols should be used for interoperable communications between Government computer systems. The Department of Defense (DoD) has established a requirement that new systems and major system upgrades should employ the OSI protocols specified in the Government Open Systems Interconnection Profile (GOSIP) as the sole mandatory interoperable protocol suite in DoD. These policies are documented in Federal Information Processing Standard (FIPS) Publication 146 and in a memorandum from the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) dated 2 July 1987. The implementation of these policies creates a requirement for various communication networks in DoD to provide the infrastructure needed to support systems using OSI protocols. The use of OSI communication protocols requires that communicating systems be assigned OSI network addresses. This document describes how these addresses are assigned and used in the DoD Internet. 1.1 SCOPE This document defines the structure, assignment procedures, and management procedures for OSI Network Addresses to be used in unclassified, fixed-plant segments of the DoD Internet. It also provides advice to network operators in determining those aspects of their local OSI addressing plans which they have authority to decide. This scheme may also be applied to classified or mobile DoD networks when analysis shows it to be operationally satisfactory. 1.2 TERMINOLOGY OSI defines two types of address-like identifiers in the Network Layer, Network Service Access Point (NSAP) addresses and Network Entity Titles (NETs). The distinction between the two is primarily that an NSAP is the address of an endpoint of network layer communication, while an NET identifies an intermediate system in a network layer communication. The same address structure is used for both NSAPs and NETs, so the term NSAP is used throughout this document and should be understood to implicitly include NETs. The OSI routing framework uses the notions of Administrative Domain and Routing Domain to define the scope within which routing-related actions occur. Since addressing is closely related to routing, the organization of portions of the global network into administrative domains and routing domains affects the assignment of NSAPs to OSI systems. An administrative domain is a portion of the global OSI network that is provides the OSI network service under the control of a single administrative entity. An administrative domain contains one or more routing domains, each of which provides routing service for some set of traffic flows within the administrative domain. The engineering aspects of an OSI network are mainly concerned with routing domains rather than administrative domains. OSI uses the term subnetwork to identify a particular interconnection facility used by network layer entities to communicate with other network layer entities. Examples of subnetworks include X.25 networks such as the MILNET backbone, LAN networks such as Ethernets, and private leased lines between systems. Subnetworks fall into three general categories: broadcast subnetworks, such as Ethernets; general topology networks, such as X.25 networks; and point-to-point subnetworks, which are dedicated links. Subnetworks do not have any specific relationship to the OSI routing architecture. A subnetwork might carry traffic between systems in the same or different routing domains. The systems connected to subnetworks are the members of routing domains, and the relationship between subnetworks and routing domains at any given time is a result of the routing domain affiliation of the connected systems and of the routing decisions made in those routing domains. 1.3 ASSUMPTIONS The scheme presented here is intended to be consistent with the following assumptions: + The scheme should be consistent with GOSIP 2.0 unless there are very strong reasons for deviation. + The scheme should be compatible with the expected characteristics of contractor off-the-shelf (COTS) products. + The scheme should assume that future versions of GOSIP will incorporate features and mechanisms now being developed in international standards bodies, and that DoD will use these features. + The scheme should be compatible with Draft International Standard (DIS) 10589 Intra-Domain Intermediate System to Intermediate System (IS-IS) routing protocol, as this is expected to be specified in a future version of GOSIP. + The scheme should support either centralized or decentralized administration of address assignment. + The scheme should allow substantial autonomy in local network routing arrangements for subscribers desiring it. + The scheme should consider the impacts of address assignment on the efficiency of packet routing in the DoD Internet. Specifically, it is desirable to minimize total path length, avoid repeated transits of the backbone, and minimize the volume of routing protocol traffic required in the DoD Internet. + The scheme should be capable of working effectively in a DoD Internet containing many more systems than the present DDN. + The scheme should be compatible with an environment containing one or many long-haul backbones. 1.4 CLARIFICATION OF INTERNATIONAL CODE DESIGNATOR (ICD) USAGE The usage of ICD 5 and ICD 6 implicit in this document is based on recent determinations by DOD, in consultation with NIST, which differ from the view stated or implied in some older documents. GOSIP Version 2 allows the use of ICD 5 by all Government agencies, including DOD. ICD 5 is administered by GSA on behalf of NIST. ICD 6 has been assigned directly to DOD. The purpose of the ICD 6 assignment is to provide an administrative framework for DOD action independent of ordinary GOSIP usage. It is currently intended that ICD 6 only be used in cases where a technical difference (as well as an administrative distinction) is involved. The only such usage at this time is in the construction of object identifiers for TCP/IP managed objects. SECTION 2 ASSIGNMENT OF GOSIP NSAP FIELD VALUES NSAPs required for MILNET devices and for systems accessing MILNET via DOD-operated networks or gateways will be assigned in accordance with a single numbering plan, defined below. This plan employs the standard GOSIP NSAP format. It is understood that the requirements for NSAP assignment in some special environments (such as highly mobile systems) have not been fully analyzed yet. It is intended that the NSAP format and assignment strategy defined here should be used in those environments if it meets the operational requirements, but other formats or assignment strategies may be adopted if this approach is found to be inadequate. 2.1 USE OF GOSIP NSAP FORMAT NSAP Addresses assigned under this plan are constructed according to the format to be specified by FIPS 146-1, GOSIP Version 2.0, when issued. The encoding and usage of these NSAPs in network traffic will comply with any applicable standards cited in GOSIP Version 2.0. 2.2 OVERVIEW OF NSAP FIELD VALUES For DoD use, the values in the fields of the GOSIP V2 NSAP are assigned as follows: AFI (Authority and Format Identifier): This will be AFI value 47, encoded as two BCD digits. IDI (Initial Domain Identifier): This will be IDI value 0005, encoded as four BCD digits, designating International Code Designator (ICD) 5. DFI (DSP Format Identifier): This will be value 128 decimal, encoded as a 1-octet binary integer, as specified by GOSIP. AAI (Administrative Authority Identifier): DCA, on behalf of DOD, will obtain a registered AAI value from the Address Registration Authority for ICD 5, for use with this numbering plan. This single value will be used in all NSAPs constructed under this numbering plan. For convenience, this value is referred to as the MILNET AAI. Other AAIs may be used in the future as requirements are defined for them. It is expected that one or more additional AAIs will be assigned for DISNET segments. AAI values are encoded as 3-octet binary integers. RESERVED: This 2-octet field will be set to zero. RD (Routing Domain): RD numbers will be assigned by the Address Registration Authority to be established by DCSO. RD numbers may be assigned either to subscriber domains or to DCA- controlled domains as appropriate to the specific requirements being supported. The DCSO Address Registration Authority will record all assignments of RD numbers under the MILNET AAI. RD numbers are encoded in the NSAP as 2-octet binary integers. AREA: AREA number assignments may be made by the administrative authority of a particular Routing Domain as necessary to meet their operational requirements. AREA numbers are encoded in the NSAP as 2-octet binary integers. The DCSO Address Registration Authority will assign area numbers within DCA-controlled routing domains as required. ID (System Identification): ID numbers will be determined in accordance with procedures of the Routing Domain to which the NSAP belongs. ID numbers may be 48-bit MAC addresses, where feasible, or other unique identifiers assigned by the administrator of the Routing Domain. THe ID number is encoded in the NSAP as a 6-octet binary integer. The DIS 10589 routing protocol forbids duplicated ID values within an area, and also requires that each ``level 2 IS'' in a routing domain have a distinct ID value. It is recommended for simplicity's sake that each routing domain require that all IDs in that routing domain be unique. NSEL (N-Selector): NSEL values may be selected by the end system or intermediate system to which the ID belongs, in compliance with the standards established by GOSIP. NSEL is encoded as a single octet. SECTION 3 DCSO REGISTRATION AUTHORITY PROCEDURES AND RESPONSIBILITIES 3.1 REGISTRATION AUTHORITY FOR MILNET AAI DCSO is responsible for establishing a Registration Authority for NSAP address assignments under the MILNET AAI. The DCSO Registration Authority has the following specific responsibilities: + The DCSO RA shall obtain an AAI assignment for the MILNET AAI from the Registration Authority for ICD 5. This assignment shall be recorded and managed in accordance with requirements specified in the GOSIP FIPS and the GOSIP User's Guide. + The DCSO RA shall accept applications from organizations authorized to use DoD communication systems for assignment of Routing Domain (RD) numbers valid within the scope of the MILNET AAI. The DCSO RA will review requests for technical validity and compliance with administrative requirements, and will furnish the requesting organization with the RD number assigned or with the reasons for not assigning an RD number. + The DCSO RA shall accept applications from organizations authorized to use DoD communication systems for assignment of AREA numbers valid within the scope of DCSO-administered RDs. The DCSO RA will review requests for technical validity and compliance with administrative requirements, and will furnish the requesting organization with the AREA number assigned or with the reasons for not assigning an AREA number. + The DCSO RA shall maintain a permanent register of all NSAP field values assigned by the RA. The register shall include the value assigned and full identification of the organization to which it has been assigned, the date of original assignment, and the date of each change to the registration information. The DCSO RA has the following additional responsibilities: + The DCSO RA shall obtain, record, and administratively manage additional AAIs for DoD activities as directed by competent authority. + The DCSO RA shall act as the holder of record for ICD 6, which has been granted to DoD by the Registration Authority for International Code Designators, and shall act as Registration Authority for all uses of ICD 6 requiring a Registration Authority. The DCSO RA may delegate any of its registration responsibilities to subsidiary authorities. Complete records of registration actions and delegations of registration responsibilities pertaining to ICD 6 shall be maintained by the DCSO RA. 3.2 USING ORGANIZATION REGISTRATION PROCEDURES Using organizations are responsible for requesting assignment of NSAP field values needed by their OSI systems. Requests should be directed to the appropriate Registration Authority for the value being requested. [Specific procedures TBD] SECTION 4 NSAP ASSIGNMENT GUIDELINES AND EXAMPLES When an OSI system comes into existence in the MILNET environment, the system must be registered with some appropriate authority in order to obtain assigned values for the RD, AREA, and ID fields of its NSAP. This section provides discussion and examples of how OSI networks and systems can be organized into routing domains and areas, and the administrative and operational effects of different choices. The first step in obtaining an NSAP for a system is always to determine an appropriate RD for the system, since the responsibility for further assignment depends on which RD is involved. The system can either be incorporated in an existing RD, or a new RD (with a newly assigned RD value) may be created. The choice should be based on the following guidelines. 4.1 CHARACTERISTICS OF A ROUTING DOMAIN A Routing Domain is formally defined as a set of ISs and ESs that employ a common routing procedure. An RD will usually be a compound entity, consisting of many hosts, and perhaps making use of many subnetworks. RDs usually contain one or more Intermediate Systems (routers). RDs will interface to other RDs through a small number of interconnections, but they may have a complex internal structure. RDs typically have the following characteristics: + All intermediate systems at the perimeter of an RD will usually be managed by a single authority. + RDs should be internally connected (that is, each system in the RD should be able to reach every other system in that RD without going through some intermediate system outside of that RD). + All ISs within an RD must perform routing in a consistent manner. This usually means that they use the same interior routing protocol and that any static routes are configured consistently throughout the RD. + The internal structure of RDs is usually invisible from the point of view of another RD. When traffic needs to flow from one RD to another, it takes the shortest path to the destination RD regardless of whether the path within the destination RD from that interconnection point to the destination system is short or long. Therefore, it is usually desirable to arrange RD boundaries so that the ``cost'' of connections within an RD is relatively insensitive to the particular path chosen. + Policy on routing of traffic exiting the routing domain currently needs to be uniform throughout a routing domain. This does not mean that every system in a routing domain must have identical rights to communicate with the outside. It does mean that for those cases in which communication is allowed, there is no way to make the choice of external path depend on which system in the RD originated the traffic. Policy-based routing protocols, which would alleviate this restriction, are still a research topic. The GOSIP address structure allots two octets for RD identification within an AAI. This allows up to 65,536 routing domains per AAI. It is expected that the actual number of RDs assigned under the MILNET AAI will be smaller, on the order of 500 to 5000 over the next several years. These routing domains are logical peers of each other, even though they may have only indirect connectivity via some other RD. 4.2 ROUTING CONSIDERATIONS IN AAI AND RD ALLOCATION In order to reduce the volume of routing information that each RD must know about, it is desirable to use AAI numbers in conjunction with RDs in such a way that useful routing decisions can be made on the basis of the AFI, IDI, DFI, and AAI fields. This implies that the AAI has some topological meaning, even though the name suggests otherwise. The concept of the MILNET AAI (and of the implicit future AAIs for DISNET or other large, topologically distinct regions of the DOD Internet) is introduced to reduce the volume of routing information needed to interconnect with other parts of the DOD or external Internets. Routing domains outside of the DDN will not need separate routing information for all of the different RDs associated with MILNET users. Conversely, systems in the RDs assigned under the MILNET AAI will not need separate routing information for each non-DOD RD with which they need to communicate. In both cases, the presence or absence of the MILNET AAI (and higher-order fields of the NSAP) identifies traffic that should be routed to the DDN ISs that support external connectivity (analogous to the current Mailbridges). Within the RDs associated with one AAI, a hierarchy of routing domains can be set up so that it will not be necessary for all ISs on RD boundaries to have complete routing information for the other RDs. This technique seems mainly useful when static inter-domain routing is used (which will be the initial situation in GOSIP networks, since dynamic inter-domain routing protocols have not yet been standardized). Each level of hierarchy introduces an extra hop in the path between two RDs that don't have direct knowledge of each other, so it is desirable to keep the hierarchy flat. A two-level hierarchy can be implemented without any special restrictions on RD number assignment. 4.3 CHARACTERISTICS OF AN AREA The AREA portion of the NSAP was provided to allow hierarchical structuring within a routing domain. Routing protocols are being developed to use the concept of Areas in specific ways. ISO DIS 10589, in particular, treats areas as distinctly addressable regions; routing domains using this protocol can be set up so that some routers (Level 1 routers) only know about the end systems in a single area, while other routers (Level 2 routers) keep track of the topology of interconnections between areas. This makes it possible to add or remove end systems without having to send routing information updates outside of the particular area affected. The choice of area boundaries should consider logical administrative divisions, reasonableness of the Level 2 topology generated, and reasonable sizes for the areas. The following guidelines are offered for defining areas that are operationally efficient: + Small routing domains should use a single AREA value. There is no specific limit on the size of a small RD, but a maximum of 5 to 10 routers and 50 to 100 end systems is suggested as a guideline. + Areas must be fully connected (every system in an area should be able to reach every other system in that area without having to go through an IS that is not in that area). + All end systems that are connected to a single broadcast subnetwork are normally organized as a single area or as a part of a single area that includes other subnetworks. + In a large routing domain, the ideal number of areas (in terms of maximizing routing efficiency) is approximately the square root of the total number of end systems and intermediate systems in the routing domain. However, it is suggested that having a smaller number of areas is better than having extremely small areas. + It may be useful to make separate areas for portions of a routing domain that are known to be unstable (systems or subnetworks going up and down frequently, frequent changes to configuration, etc.) to isolate the rest of the routing domain from having to process all of the routing updates generated by those systems. 4.4 EXAMPLES OF NSAP ASSIGNMENT FOR DIFFERENT CONFIGURATIONS 4.4.1 Concentrator Installation as a Routing Domain One widely employed network configuration uses a ``concentrator'' (an OSI Intermediate System and one or more associated local subnetworks) to connect many devices at a base, post, camp, or station to the MILNET. There are two possible ways of arranging the addressing for such a configuration: as an area or as a routing domain. It will probably be most common to have a distinct RD assigned for each such base concentrator and the devices it serves. The administrator of each such Routing Domain assigns AREA and ID values to the systems that access the DDN through the concentrator. If a base network is connected to the DDN through more than one IS, it is still possible and often appropriate to organize the entire complex as a single routing domain with one RD number. This assumes that the complex as a whole meets the technical constraints on a routing domain as described previously. There may be smaller portions of a base network which should become separate Routing Domains to accommodate a special requirement, such as rapid redeployability of an organization's network at another location or a need to use a routing strategy incompatible with the rest of the base network. These situations will need to be analyzed on a case-by-case basis. Section 4.4.4 below discusses deployable organizational networks. 4.4.2 Concentrator Installation as an Area of a DDN Routing Domain DCSO may establish a service in which using organizations may attach one or more subnetworks to a DDN-operated Routing Domain using a subscriber-controlled Intermediate System (IS). If this service is established, organizations subscribing to the service must request that DCSO assign an AREA number within the DDN-operated RD. In this situation, registration of ID numbers for end systems within the AREA will be the responsibility of the organization to which the AREA number is assigned. The ID numbers for ISs must either be derived from a global registry (such as globally unique MAC addresses) or will be assigned by DCSO, in order to ensure uniqueness throughout the RD. 4.4.3 End Systems Directly Connected to a DDN Subnetwork An end system connected directly to the MILNET could either be attached to some existing Routing Domain, if this is desired, or may be assigned to a DDN-controlled Routing Domain otherwise. In either case, traffic destined for such an ES will always transit an IS in the destination ES's routing domain unless the traffic source is another ES on the same subnetwork. As a result, traffic coming from other RDs will usually take one extra hop. Since the router in the destination's RD will be charged for this extra hop, most subscribers will probably prefer to affiliate with a DDN- controlled routing domain. If an ES subscriber on a DDN backbone segment does not become part of a subscriber-operated Routing Domain, DCSO will assign RD, AREA, and ID values for the subscriber system. It is 1 currently expected that a single RD value and a single AREA value will be used for all such assignments for hosts connected directly to MILNET, but this may evolve to meet requirements as they are identified. If a subscriber wants to put an ES into an existing subscriber-operated Routing Domain, the subscriber needs to contact the Registration Authority for that RD to acquire AREA and ID assignments. In this configuration, the ES must be configured with the NSAP of at least one IS in the routing domain, which serves as a source of routing information. 4.4.4 Deployable Networks Some organizations have networks that are expected to be deployable with the unit they support. After a deployment occurs, connectivity to the DDN would be reestablished using whatever connection facilities are available at the deployed location. To support this application, the set of equipment which would be deployed together should be organized as a separate routing domain. Routing arrangements would be set up at the current location (regular or deployed) to connect this RD to some RD readily accessible at that location. The rationale for using a separate RD is to avoid having to change addresses as part of a deployment action. If the deployed systems were part of a RD located elsewhere, it would often be difficult to keep the RD internally connected (which is necessary for routing to work correctly). To take advantage of subnetworks or RDs available at the deployed location, the deployed systems have to either become part of a RD there, or become a peer RD. Setting up such a collection of systems as a distinct RD even when not deployed will minimize the effort needed to establish communications when a deployment occurs.